After the user-functional specification has been created for an integrated circuit, the circuit designer must next transform the user specification into a register-transfer level (RTL) description that specifies the logical design of the IC. More specifically, the RTL declares the registers that synchronize the operation of the IC to the clock cycle, and it specifies the combinational logic that performs the logical functions of the IC. In addition to describing the desired behavior of logical circuits, the RTL specifies the interconnections to inputs and outputs.
In the physical design stage, a logic synthesis tool is typically used to convert the RTL to a gate-level description of the IC. More specifically, the synthesis software, operating on the RTL description, generates a logically equivalent description referred to as a “netlist”.
The netlist consists of elementary logic primitives drawn from whatever set of such primitives is available in the pertinent physical integrated circuit technology. Many of the elementary logic primitives may be provided by manufacturers as “cells” belonging to a proprietary cell library.
A typical netlist includes a definition for each occurrence of such an elementary logic primitive. The definition lists the ports (or “pins”) that are the connection points to the primitive, and it may also define certain properties of the primitive. The netlist also lists the wires, referred to as “nets,” that interconnect the primitives and other elements of the IC. The netlist associates the nets, by name, to the ports to which they are connected.
Placement and routing tools process the netlist to create a physical layout for the IC.
Application-specific integrated circuits (ASICS) are a class of ICs that have rapidly growing commercial importance. An ASIC is an IC whose design is customized for a particular use. As the demand for ASICs has grown, so has their complexity. Indeed, a contemporary ASIC may have as many as 100 million gates or more.
Not surprisingly, manufacturers of ASICs must perform post-fabrication testing to screen out parts with manufacturing defects. For effective testing, it is necessary to gain access to internal blocks within the circuit under test (CUT). Absent special provisions, it would be impractical to attempt such access from the primary input-output (I/O) pins of the CUT.
Designers have therefore made a special provision for test access, referred to as a test port. The test port is a combination of logic and I/O pins. A body of techniques, referred to as “Design for Test (DFT)”, has evolved for incorporating test-port logic and test-port I/O into ASIC designs, among others. DFT features are typically included in the RTL description of the ASIC.
Standardized test ports, e.g. JTAG1-compatible test ports, are generally available for implementation in commodity IC devices. However, it is more typical to implement proprietary test-port interfaces in custom ASICs. In addition, custom ASICs intended for high-reliability applications often have more stringent test-port usage requirements than those that are typically implemented in commercial test-port IP blocks. Hence these devices in particular will generally implement custom or proprietary test-port interfaces.
The development and implementation of custom or proprietary test-port interfaces has associated costs that could be very high. Because the test port is likely to be highly unique to a particular ASIC design, it will often be necessary to manually develop the hardware source code using an RTL language such as Verilog or VHDL. The effort can be complex, not least because it will in many cases require the multiplexing of hundreds of signals from the logic core.
Moreover, there is often a demand to update the source code late in the ASIC design cycle as the core design is finalized.
These factors drive up costs for various reasons. For example, efforts must be duplicated because the manually developed test-port interfaces are not re-usable across ASIC designs. Moreover, the test-port interfaces are prone to logic bugs, and the test-port interfaces are resource-intensive to generate and validate. Hence, there is a need for a more economical approach for developing and implementing ASIC test-port interfaces.